1. Field of the Invention
The present invention relates to a wireless communications network. In particular, the present invention discloses a method for determining when to establish a RLC entity during a 3GPP SRNS relocation procedure.
2. Description of the Prior Art
Please refer to FIG. 1. FIG. 1 is a simple block diagram of a wireless communication network 10, as defined by the 3rd Generation Partnership Project (3GPP) specifications 3GPP TS 25.322 V3.10.0 “RLC Protocol Specification”, and 3GPP TS 25.331 V3.10.0 “Radio Resource Control (RRC) Specification”, which are included herein by reference. The wireless communications network 10 comprises a plurality of radio network subsystems (RNSs) 20 in communications with a core network (CN) 30. The plurality of RNSs 20 is termed a Universal Mobile Telecommunications System (UMTS) Terrestrial Radio Access Network, or UTRAN for short. Each RNS 20 comprises one radio network controller (RNC) 22 that is in communications with a plurality of Node Bs 24. Each Node B 24 is a transceiver, which is adapted to send and receive wireless signals, and which defines a cell region. A number of cells (i.e., a number of Node Bs 24) taken together defines a UTRAN Registration Area (URA). In particular, the wireless communications network 10 assigns a mobile unit 40 (generally termed a “UE” for User Equipment) to a particular RNS 20, which is then termed the serving RNS (SRNS) 20s of the UE 40. Data destined for the UE 40 is sent by the CN 30 (or UTRAN 20u) to the SRNS 20s. It is convenient to think of this data as being sent in the form of one or more packets that have a specific data structure, and which travel along one of a plurality of radio bearers (RBs) 28, 48. An RB 28 established on the SRNS 20s will have a corresponding RB 48 established on the UE 40. The RBs are numbered consecutively, from RB0 to RBn. Typically, RB0 to RB4 are dedicated signaling RBs (SRBs), which are used for passing protocol signals between the UTRAN 20u and the UE 40, and will be described in some more detail below. RBs 28, 48 greater than four (i.e., RB5, RB6, etc.) are typically used to carry user data. The RNC 22 utilizes a Node B 24, which is assigned to the UE 40 by way of a Cell Update procedure, to transmit data to, and receive data from, the UE 40. The Cell Update procedure is initiated by the UE 40 to change a cell as defined by a Node B 24, and even to change a URA. Selection of a new cell region will depend, for example, upon the location of the UE 40 within the domain of the SRNS 20s. The UE 40 broadcasts data to the wireless communications network 10, which is then picked up by the SRNS 20s and forwarded to the CN 30. Occasionally, the UE 40 may move close to the domain of another RNS 20, which is termed a drift RNS (DRNS) 20d. A Node B 24 of the DRNS 20d may pick up the signal transmitted by the UE 40. The RNC 22 of the DRNS 20d forwards the received signal to the SRNS 20s. The SRNS 20s uses this forwarded signal from the DRNS 20d, plus the corresponding signals from its own Node Bs 24 to generate a combined signal that is then decoded and finally processed into packet data. The SRNS 20s then forwards the received data to the CN 30. Consequently, all communications between the UE 40 and the CN 30 must pass through the SRNS 20s. 
Please refer to FIG. 2 in conjunction with FIG. 1. FIG. 2 is a simple block diagram of a UMTS radio interface protocol architecture, as used by the communications network 10. Communications between the UE 40 and the UTRAN 20u is effected through a multi-layered communications protocol that includes a layer 1, a layer 2 and a layer 3, which together provide transport for a signaling plane (C-plane) 92 and a user plane (U-plane) 94. Layer 1 is the physical layer 60, and in the UTRAN 20u is responsible for combining signals received from the DRNS 20d and SRNS 20s. Layer 2 includes a packet data convergence protocol (PDCP) layer 70, a Radio Link Control (RLC) layer 72, and a Medium Access Control (MAC) layer 74. Layer 3 includes a Radio Resource Control (RRC) layer 80. The U-plane 94 handles user data transport between the UE 40 and the UTRAN 20u, whereas the C-plane 92 handles transport for signaling data between the UE 40 and the UTRAN 20u. The RRC 80 sets up and configures all RBs 28, 48 between the UTRAN 20u and the UE 40. The PDCP layer 22 provides header compression for Service Data Units (SDUs) received from the U-plane 94. The RLC layer 72 provides segmentation of PDCP 70 SDUs and RRC 80 SDUs into RLC protocol data units (PDUs), and under acknowledged mode (AM) transfers, can provide upper layers (such as the PDCP layer 70 or the RRC layer 80) with a confirmation that RLC PDUs have been successfully transmitted and received between the UTRAN 20u and the UE 40. The MAC layer 74 provides scheduling and multiplexing of RLC PDUs onto the transport channel, interfacing with the physical layer 60.
Before proceeding, it is worth taking note of terminology used in the following. An SDU is any packet that is received from an upper layer or passed to an upper layer, whereas a PDU is a packet generated by a layer and passed on to a lower layer or received from a lower layer. Hence, a PDCP PDU is an RLC SDU. Similarly, an RLC PDU is a MAC SDU, and so forth. Generally, a PDU is formed by adding a header to SDU data received from an upper layer, or by internally generating a packet for layer-to-layer communications between the UE 40 and the UTRAN 20u. Of particular relevance to the present invention is the RLC layer 72 in the layer 2 stack. The RLC layer 72 generates RLC PDUs of a fixed size that is determined by the MAC layer 74, and sends these RLC PDUs to the MAC layer 74 for transmission, or receives RLC PDUs from the MAC layer 74. Each RLC PDU explicitly carries an n-bit sequence number in its header that identifies the sequential position of that RLC PDU in a stream of RLC PDUs, and which thus enables RLC PDUs to be assembled in their proper order to form RLC SDUs (i.e., PDCP PDUs, or RRC PDUs). The RLC layer 72 is composed of one or more RLC entities 76. Each RLC entity 76 is individually associated with an RB 28, 48. For an RB 28 on the UTRAN 20u side, there exists an RLC entity 76 dedicated solely to that RB 28. For the same RB 48 on the UE 40 side, there similarly exists a corresponding RLC entity 76. These two corresponding RLC entities 76 for the same RB 28, 48 are termed “RLC peer entities”. The value of “n” for the n-bit sequence numbers carried within the headers of the RLC PDUs will depend on the transport mode utilized between the RLC peer entities 76. For example, in AM transmissions, in which the RLC peer entities 76 acknowledge each RLC PDU successfully received, n is 12. In other transport modes, n is 7. For communications between the UTRAN 20u and the UE 40 to be successful, it is essential that the RLC peer entities 76 be properly synchronized with each other. In particular, each RLC entity 76 contains two hyperframe numbers (HFNs): a receiving HFN (rHFN) 76r, and a transmitting HFN (tHFN) 76t. The tHFN 76t and rHFN 76r are used for encryption and decryption of packet data, respectively. For this encryption/decryption process to be successful, RLC peer entities 76 must have synchronized rHFN 76r and tHFN 76t values. In particular, the rHFN 76r of one RLC entity 76 must be identical to the tHFN of its RLC peer entity 76, and vice versa. As RLC PDUs are transmitted by an RLC entity 76, the tHFN 76t steadily increases in value. As RLC PDUs are received by an RLC entity 76, the rHFN 76r steadily increases in value. The rHFN 76r counts how many times rollover is detected in the sequence numbers of received RLC PDUs. The tHFN counts how many times rollover is detected in the sequence numbers of transmitted RLC PDUs. The HFNs 76r, 76t may thus be thought of as non-transmitted high-order bits of the RLC PDU sequence numbers, and it is essential that these HFNs 76r, 76t are properly synchronized on the RLC peer entities 76.
It is the RRC layer 80 that is responsible for the establishment and configuring of the RBs 28, 48. The RRC layer 80 has various operational states that affect how the RRC layer 80 behaves. Please refer to FIG. 3 with reference to FIG. 1 and FIG. 2. FIG. 3 is a state diagram of the RRC layer 80. The RRC layer 80 has two primary states: an idle mode 81 and a UTRA RRC Connected Mode 86. While in idle mode, the RRC layer 80 has no lines of communication open with its peer RRC layer 80. That is, there are no available SRBs 28, 48 that enable communications between peer entity RRC layers 80, except for RB0, which is a common channel available to all UEs 40 in the UTRAN 20u. Utilizing the UE 40 as an example platform, once the RRC layer 80 of the UE 40 establishes a connection (i.e., an SRB 28, 48) with its peer RRC layer 80 on the UTRAN 20u, the RRC layer 80 of the UE 40 switches into the UTRA RRC Connected Mode 86. This connection is typically initiated along RB0, which is a shared channel. Internally, the UTRA RRC Connected Mode 86 has four unique states: CELL_DCH 82, CELL_FACH 83, CELL_PCH 84 and URA_PCH 85. The CELL_DCH state 82 is characterized in that a dedicated channel is allocated to the UE 40 for uplink (UE 40 to UTRAN 20u) and downlink (UTRAN 20u to UE 40) communications. The CELL_FACH state 83 is characterized in that no dedicated channel is allocated to the UE 40, but instead the UE 40 is assigned a default common or shared transport channel for uplink. The CELL_PCH state 84 is characterized in that no dedicated physical channel is allocated to the UE 40, no uplink activity is possible for the UE 40, and the position of the UE 40 is known by the UTRAN 20u on a cell level (i.e., a node B basis 24). The URA_PCH state 85 is characterized in that no dedicated physical channel is allocated to the UE 40, no uplink activity is possible for the UE 40, and the position of the UE 40 is known by the UTRAN 20u on a URA basis.
A number of reconfiguration procedures are available to the RRC layer 80 to setup and configure RBs 28, 48. These procedures involve the UTRAN 20u sending a specific message to the UE 40 along an RB 28, 48, and the UE 40 responding in turn with a corresponding message. Typically, the message is sent along RB2, which is an SRB. The messages include Radio Bearer Setup, Radio Bearer Reconfiguration, Radio Bearer Release, Transport Channel Reconfiguration and Physical Channel Reconfiguration. For each of these reconfiguration messages, the UE 40 has a corresponding “Complete” or “Failure” response message indicating success or failure of the procedure on the UE 40 side, and which may provide the UTRAN 20u any necessary information for the UTRAN 20u to complete the procedure. The reconfiguration message and the response message may all carry optional information elements (IEs), which are fields of data that hold ancillary information. In addition to these reconfiguration procedures, there also exists a Cell Update procedure, which originates with a Cell Update message from the UE 40 and which is responded to by the UTRAN 20u. The Cell Update procedure is used by the UE 40 to indicate a change of cell location (i.e., Node B 24), of URA, or connection state 82, 83, 84 and 85.
As the UE 40 moves closer towards the domain of the DRNS 20d, a decision is eventually made by the UTRAN 20u to place the UE 40 under the DRNS 20d, and a transfer process is enacted so that the DRNS 20d will become the new SRNS 20s of the UE 40. This process is termed an SRNS relocation procedure. The SRNS relocation procedure may be combined with any of the previously noted RRC procedures. In particular, by including a “New U-RNTI” IE in with a Radio Bearer Reconfiguration message, an SRNS relocation procedure is triggered. For the other procedures (Radio Bearer Setup, Radio Bearer Release, Transport Channel Reconfiguration, Physical Channel Reconfiguration and Cell Update), inclusion of a “Downlink counter synchronization info” IE will trigger SRNS relocation.
When receiving a reconfiguration message (which is sent from the SRNS 20s along RB2 28) that indicates that SRNS relocation is to be performed, the UE 40 re-establishes the RLC entity 76 of RB2 48, and re-initializes the rHFN 76r and the tHFN 76t for RB2 48. The RLC entity 76 for RB2 48 is re-established with a peer entity 76 on the DRNS 20d, which will serve as the new SRNS 20s for the UE 40. The new values for the rHFN 76r and tHFN 76t for RB2 48 are given by the equation: MAX(rHFN of RB2, tHFN of RB2)+1, where MAX(a, b) selects the larger of a or b. The UE 40 then calculates a START value for each CN 30 domain and includes these START values in a “START list” IE within the response message. START values are used to initialize the rHFNs 76r and tHFNs 76t of all other RBs 48, 28 except RB0. The START value used to initialize the rHFN 76r, tHFN 76t of an RB 48, 28 depends upon the domain with which the particular RB 48, 28 is associated. Currently, there are two domains: a packet switching (PS) domain 30p, and a circuit switching (CS) domain 30c. Hence, the START list IE currently contains two values: a START value for the PS domain 30p, and a START value for the CS domain 30c. The UE 40 then transmits the response message, which contains the START list IE, to the UTRAN 20u along RB2 48. The RLC entity 76 of RB2 48 is an AM connection, and so the RRC layer 80 of the UE 40 is able to know if the UTRAN 20u has successfully received the response message, as the RLC entity 76 will so inform the RRC layer 80. After the RLC layer 76 of RB2 48 has confirmed the successful transmission of the response message, and if the new state of the RRC layer 80 of the UE 40 is the CELL_DCH state 82 or the CELL_FACH state 83, the RRC layer 80 of the UE 40 re-establishes the RLC entities 76 for all other RBs 48 (except RB0, which is the common channel), and re-initializes the rHFN 76r and tHFN 76t of these RBs 48 with the appropriate START value that was included in the response message to the UTRAN 20u. 
Because the RBs 48 are re-established only if the new state of the RRC layer 80 is the CELL_DCH state 82 or the CELL_FACH state 83 when confirmation to the response message is received, problems may arise if the SRNS relocation procedure is performed and the UE 40 slips into the CELL_PCH state 85 or URA_PCH state 84. This problem may occur due to the periodic nature in which the Cell Update procedure is performed by the UE 40. In the event that the new state of the RRC layer 80 of the UE 40 is one of the CELL_PCH 85 or URA_PCH 84 states during the SRNS relocation procedure, the RLC entities 76 of the other RBs 48 (i.e., RB1, RB3, RB4, . . . , RBn) will not be re-established, nor will their HFN values 76r, 76t be re-initialized. As a result, once the RRC layer 80 of the UE 40 transitions back into either the CELL_DCH state 82 or the CELL_FACH state 83, these RLC entities 76 will not be properly synchronized with their RLC peer entities 76 on the UTRAN 20u side. This lack of synchronization will cause the ciphering/deciphering process to break down, and consequently communications along these RBs 28, 48 will no longer be functional.